You are here: Integrations > SSO - Integration Connections > SSO Information for Your IT Department

SSO Information for Your IT Department

The information presented in this topic refers to the self service Learn Single Sign-On (SSO) feature. If you have a custom SSO built by the Oracle Learn Cloud Services team, and you are looking for assistance, please refer to any documentation they have provided.

Before you can set up Learn Single Sign-On (SSO), you will need to gather some information from your Information Technology (IT) Department or personnel. Share this topic with IT so that they can provide you with the necessary information for setting up your side of the Learn SSO. You can print this topic if necessary by clicking the print icon at the top of online help.

If you are a member of IT staff and you have been presented with this page, you will need to provide some key pieces of information so that your LearnCenter Administrator can properly set up Learn SSO. This topic has been written specifically with IT personnel in mind and provides you with an overview of the feature and related technical information.

Overview

Learn SSO enables your organization to integrate LearnCenter with a corporate Intranet or website. Once set up, your Users can sign in to your corporate intranet or website, and then access LearnCenter without the need to sign in a second time using their LearnCenter login credentials. You can set up SSO at either the root or the sub LearnCenter level. You can set up an SSO connection for the root and define a scope of LearnCenters that includes the root and all Sub-LearnCenters. You could also set up a connection that includes a sub LearnCenter and all of its child sub LearnCenters. The choice is yours, and you can set up an unlimited number of connections. Learn SSO is considered a "Self Service" feature, because your LearnCenter Administrator can easily configure it, with input from IT, without the need to pay for technical consulting. There is no additional cost to use this enhancement, and you do not need to notify Oracle if you begin using it.

Terminology

This section provides an overview of terminology used in this topic. While this terminology is new for LearnCenter, it is not new in general, and you are probably already familiar with the concepts. We have provided both definitions and URLs pointing to sites that provide deeper documentation on these subjects if you need it.

CollapsedClick here to review the terminology and links to additional external information.

SP-Initiated SAML

LearnCenter SSO supports the SAML standard, versions 1.1 and 2.0. SAML 2.0 is backward compatible and is the default setting, but you can still implement SSO with 1.1 if that suits your needs.

While SAML is available in two "flavors": SP-initiated (Service Provider Initiated) and IDP-Initiated (Identity Provider Initiated), the Learn SSO functionality supports SP-initiated implementation only.

SP-initiated SAML enables End Users to simply browse to Learn pages and log in. Behind the scenes and seamless to the Users, their information is redirected to the IdP, which authenticates the User and sends them back to LearnCenter.

Web browser Single Sign-On (SP-Initiated)

Most often, Users visit an SP site through a browser bookmark or direct link. In these scenarios, the User initiates the request (User Agent) by selecting a link or bookmark to the LearnCenter login page (SP) that would generate a SAML authentication request and send a redirect to the browser for the request to be submitted to Customer’s SSO URL (IdP). The User’s identity information is provided to Learn and the User is authenticated into the LearnCenter and directed to the default home page. This is also known as SP-Initiated.

The process for the LearnCenter SAML SSO via browser post:

  1. A User attempts to reach a protected (closed) LearnCenter, which requires User authentication.
  2. LearnCenter generates a SAML authentication request, and sends a redirect to the browser for the request to be submitted to Customer’s SSO URL. The SAML request is encoded (Base 64 encoding) and embedded into the URL (SAMLRequest query string parameter) for your SSO service. The optional RelayState parameter containing the encoded URL of the originally requested Learn page that the User is trying to reach may also be embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection, and it’s only used if Deep Linking is required.
  3. LearnCenter sends a redirect to the User's browser. The redirect URL includes the encoded SAML authentication request that should be submitted to your SSO service. Your service decodes the SAML request and authenticates the User.
  4. The IDP parses the SAML request and extracts the URL for both the Assertion Consumer Service and the User's destination URL (RelayState). You then authenticate the User. You could authenticate Users by either asking for valid login credentials or by checking for valid session cookies. You generate a SAML response with an assertion. The response is digitally signed with your private key.
  5. The IDP generates a SAML response that contains the authenticated User's username. In accordance with the SAML 2.0 specification, this response is digitally signed with your RSA private keys. The public key should be included in the X509 Certificate XML node so Learn can verify the signature. The assertion is posted to the LearnCenter the SAML Login Handler page, which is the SAML endpoint URL.
  6. IDP encodes the SAML response and the RelayState parameter and returns that information to the User's browser. You provide a mechanism so that the browser can forward that information to LearnCenter. For example, you could embed the SAML response and destination URL in a form and provide a button that the User can click to submit the form to LearnCenter. You could also include an ‘onload’ JavaScript on the page that automatically submits the form to LearnCenter.
  7. The Learn SAML Login Handler verifies the SAML response using your public key. If the response is successfully verified, the User will be granted access to LearnCenter.
  8. The User is redirected to the destination URL, and is logged in to LearnCenter.

What is Needed From IT

Either IT or the LearnCenter Administrator will need to create the Integration Connection within the LearnCenter application for the scope of LearnCenters to be included in SSO. This is done on the Add Integration Connections page accessed from the LearnCenter's Control Panel. Most of the information required on that page is unique to your organization and can be provided by IT. Use the following table like a worksheet or checklist to gather the information necessary to complete the fields on the Add Integration Connections page.

Field Requirement IT Department Data
IDP Identifier for your organization’s identity provider. You must provide the SAML issuer that is in your organization’s Assertion. For example:

<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> .
 
SAML Protocol (2.0 or 1.1)  
IDP Unique Identifier. This is a required field that will map your IDP’s unique identifier to the LearnCenter unique identifier. This free form field is limited to 50 characters.Enter the identity provider's value that uniquely identifies the User. In the SAML SSO it is expected that the User’s Unique ID will be sent in the SAML NameID.

For example:

 

<samlp:NameIDPolicy

AllowCreate="false"

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>

</samlp:AuthnRequest>

 

<saml:NameID

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">

3f7b3dcf-1674-4ecd-92c8-1544f346baf8

</saml:NameID>

 

NOTE: The value entered in the text box is case sensitive and must be an exact match to your IDP value.

 

Learn Unique Identifier. Required field that allows for selection of the unique identifier to be used in your Learn implementation to identify the user that is access the system. Standard and custom User fields are available to give you flexibility in determining your unique identifier.

  • Username
  • Email
  • Email2
  • Custom fields. Rules for using Custom fields: The custom field must be a text box, and it must be a shared User field. It also must be a field that was created at the same level (Root or Sub-LearnCenter) for which the SSO connection is being configured.
 
  • Authentication URL. This is a required field that must contain the URL to which authentication requests will be redirected. This is a free form text field that must be completed correctly.
  •  
    Logout Page URL. Some IDPs support logout requests from the service provider. When a User logs out of LearnCenter, the session ends, and if you have entered a Logout Page URL here, then a logout post will be sent to the IDP as well.  
    Error Page URL. Some IDPs support error messages for failed login attempts from the service provider. When an error occurs, if you have entered an Error Page URL here, then the error message will be posted to the IDP to be displayed to the User. If no URL is present, the error information will be displayed on the LearnCenter error model.  
    SSO Certificate. This is a third party security certificate. Required to upload the X509 certificate. Provide this to your LearnCenter Administrator or upload the certificate on the Add Integration Connections page.
    Existing Certificates. Requires that a X509 certificate has been uploaded and selected. Provide these to your LearnCenter Administrator or upload the certificates on the Add Integration Connections page.

    Related Topics IconRelated Topics

     

    Copyright © 2010-2015, Oracle and/or its affiliates. All rights reserved.